In computer storage, logical volume management or LVM provides a method of allocating space on mass-storage devices that is more flexible than conventional partitioning schemes. In particular, a volume manager can concatenate, stripe together or otherwise combine partitions into larger virtual ones that administrators can re-size or move, potentially without interrupting system use.
Volume management represents just one of many forms of storage virtualization; its implementation takes place in a layer in the device-driver stack of an OS (as opposed to within storage devices or in a network).
Contents |
Most volume-manager implementations share the same basic design. They start with physical volumes (PVs), which can be either hard disks, hard disk partitions, or Logical Unit Numbers (LUNs) of an external storage device. Volume management treats PVs as sequences of chunks called physical extents (PEs). Some volume managers (such as that in HP-UX and Linux) have PEs of a uniform size; others (such as that in Veritas) have variably-sized PEs that can be split and merged at will.
Normally, PEs simply map one-to-one to logical extents (LEs). With mirroring, multiple PEs map to each LE. These PEs are drawn from a physical volume group (PVG), a set of same-sized PVs which act similarly to hard disks in a RAID1 array. PVGs are usually laid out so that they reside on different disks and/or data buses for maximum redundancy.
The system pools LEs into a volume (VG). The pooled LEs can then be concatenated together into virtual disk partitions called logical volumes or LVs. Systems can use LVs as raw block devices just like disk partitions: creating mountable file systems on them, or using them as swap storage.
Striped LVs allocate each successive LE from a different PV; depending on the size of the LE, this can improve performance on large sequential reads by bringing to bear the combined read-throughput of multiple PVs.
Administrators can grow LVs (by concatenating more LEs) or shrink them (by returning LEs to the pool). The concatenated LEs do not have to be contiguous. This allows LVs to grow without having to move already-allocated LEs. Some volume managers allow the re-sizing of LVs in either direction while online. Changing the size of the LV does not necessarily change the size of a filesystem on it; it merely changes the size of its containing space. A file system that can be resized online is recommended in that it allows the system to adjust its storage on-the-fly without interrupting applications.
PVs and LVs cannot be shared between or span different VGs (although some volume managers may allow moving them at will between VGs on the same host). This allows administrators conveniently to bring VGs online, to take them offline or to move them between host systems as a single administrative unit.
VGs can grow their storage pool by absorbing new PVs or shrink by retracting from PVs. This may involve moving already-allocated LEs out of the PV. Most volume managers can perform this movement online; if the underlying hardware is hot-pluggable this allows engineers to upgrade or replace storage without system downtime.
Some volume managers also implement snapshots by applying copy-on-write to each LE. In this scheme, the volume manager will copy the LE to a copy-on-write table just before it is written to. This preserves an old version of the LV—the snapshot—which systems can later reconstruct by overlaying the copy-on-write table atop the current LV. Read-write snapshots are branching snapshots because they implicitly allow diverging versions of an LV.
Snapshots can be useful for backing up self-consistent versions of volatile data like table files from a busy database, or for rolling back large changes (such as an operating system upgrade) in a single operation. Some Linux-based Live CD systems also use snapshots to simulate read-write access on a read-only compact disc.
Vendor | Introduced in | Volume manager | Allocate anywhere[1] | Snapshots | RAID 0 | RAID 1 | RAID 5 | RAID 10 | Notes |
---|---|---|---|---|---|---|---|---|---|
IBM | AIX 3.0 (1989) | Logical Volume Manager | Yes | No[2] | Yes | Yes | No | Yes[3] | [4] |
Hewlett-Packard | HP-UX 9.0 | HP Logical Volume Manager | Yes | Yes | Yes | Yes | No | Yes | |
FreeBSD | Vinum Volume Manager | Yes | No | Yes | Yes | Yes | [5] | ||
NetBSD | Logical Volume Manager | Yes | No | Yes | Yes | No[6] | No | [7] | |
Linux 2.2 | Logical Volume Manager | Yes | Yes | Yes | Yes | No | |||
Linux 2.4 | Enterprise Volume Management System | Yes | Yes | Yes | Yes | Yes | |||
Linux 2.6 | Logical Volume Manager | Yes | Yes | Yes | Yes | No | |||
Silicon Graphics | IRIX or Linux | XVM Volume Manager | Yes | Yes | Yes | Yes | Yes | ||
Sun Microsystems | SunOS | Solaris Volume Manager (was Solstice DiskSuite). | No | No | Yes | Yes | Yes | Yes | [8] |
Sun Microsystems | Solaris 10 | ZFS | Yes | Yes | Yes | Yes | Yes | Yes | |
Veritas[9] | Cross-OS | Veritas Volume Manager (VxVM) | Yes | Yes | Yes | Yes | Yes | Yes | [10] |
Microsoft | Windows 2000 and later NT-based operating systems | Logical Disk Manager | Yes | Yes[11] | Yes | Yes | Yes | No | [12] |